上一篇介紹了 Attack Surface，找出了 AI 系統中可能遭到攻擊的位置，但知道「哪裡可能被攻擊」還不夠，實際開發一個系統時，我們還需要繼續思考誰可能攻擊這個系統？他想取得什麼？會用什麼方式攻擊？如果真的成功會造成多大的影響？這就是 Threat Modeling（威脅建模）想解決的問題。
Threat Modeling 是一種用來識別、分析威脅，並思考如何降低風險的方法，而且它最好不是等系統開發完成才進行，而是在設計、開發過程中持續更新。
OWASP 提供了一個很適合入門的 Four Question Framework：
假設今天公司建立了一個內部 AI Assistant。
員工可以問它：「公司的請假規定是什麼？」「幫我找今年的專案文件。」
AI 會搜尋公司的內部知識庫，再根據找到的資料回答問題，我們就拿這個系統來做一次簡單的 Threat Modeling。
這時候可以開始整理：
系統有哪些元件？
資料會流向哪裡？
系統會接觸哪些重要資料？
哪些地方存在不同的權限或信任關係？
例如這套系統中可能存在一般員工資料、內部專案文件或主管機密文件，不同資料的敏感程度與存取權限都不一樣，實際進行 Threat Modeling 時，通常也會使用 Data Flow Diagram（DFD） 等方式，把系統元件與資料流畫出來，知道自己的系統怎麼運作之後才可以分析問題。
例如可能發現一般員工可能透過 AI Assistant 取得原本沒有權限查看的主管文件，這時候就可以進一步建立威脅情境：
一般員工 → AI Assistant → 搜尋內部資料 → 取得未授權文件
實際 Threat Modeling 並不只有一種尋找威脅的方法，所以也可以繼續找其他可能發生的問題，像是可以使用 STRIDE、Attack Trees、Kill Chains 等方法協助分析。
用剛剛的例子來說，那我們可能需要在資料檢索時驗證使用者權限、依照部門或角色限制資料存取、記錄敏感文件的存取行為，實際上還可以根據風險選擇 Mitigate（降低風險）、Eliminate（消除風險）、Accept（接受風險）、Transfer（轉移風險），所以更重要的是我們怎麼處理這個風險。
例如剛剛加入了資料權限驗證，就需要重新確認：
一般員工現在真的無法透過 AI Assistant 取得主管文件嗎？
除此之外，Threat Model 也不是做完一次就永遠不用再碰，假設之後 AI Assistant 新增：
「可以直接寄 Email」
這代表系統的能力與 Attack Surface 都改變了，原本的 Threat Model 就應該重新檢查，因此 Threat Modeling 比較像是一個持續更新的過程，而不是開發初期做完一份文件就結束。
把四個問題放在一起
最後把剛剛的案例整理一下：
What are we working on? 可以搜尋公司內部文件的 AI Assistant
What can go wrong? 員工可能取得沒有權限查看的文件
What are we going to do about it? 加入資料存取權限與紀錄機制
Did we do a good job? 測試權限是否真的能阻止未授權存取
這就是一次非常簡化的 Threat Modeling，真正的系統當然會比這複雜很多，但核心思考方式其實就是：
了解系統 → 找出威脅 → 處理威脅 → 驗證結果
Threat Modeling 本身並不是 AI 出現之後才有的技術，傳統 Web Application、Cloud、Network 等系統本來就會使用 Threat Modeling，只是當 AI 加入系統之後我們分析的對象又增加了，所以 AI Threat Modeling 並不是重新發明一套資安方法，而是把原本的 Threat Modeling 方法套用到新的 AI 系統架構與威脅上。
這篇我們第一次實際站在攻擊者的角度，對一個 AI Application 做簡單的 Threat Modeling，先找出要保護的東西，再思考誰可能攻擊、攻擊者想做什麼、可能造成什麼影響，最後決定哪些風險應該優先處理。
到這裡，我們第一週其實了解了從「AI 是怎麼運作的」，一路走到了「如何開始分析一個 AI 系統的安全問題」，
而從下一篇開始，就要進入第二週的 LLM 攻擊與漏洞，第一個要深入研究的就是前面已經出現很多次的Prompt Injection，也盡量會帶入一些真實案件去慢慢研究。
iThome鐵人賽
看影片追技術